Nectar Logo

User-Centred Requirements Handbook

Telematics Engineering Logo

Phase 2. Prototype and User test


2.1 General usability goals and guidelines

Objective

The aims of this section are to:

• Specify general usability goals for the system and,

• Review guidelines or styles guides to which the user interface should conform, and possibly to produce a short checklist.

Process

General usability goals

1. Review the following general usability goals shown in Form 2.1, write in the second column any specific details about how that goal will apply to the current system.

2. Identify those that are particularly relevant to the system and mark these appropriately (e.g. with a tick, ).

The information collected in Stage 1 can be used to highlight the kinds of usability goals that may be important.

Thus for example if the users are the general public who are to use, say, an information system on a walk up and use basis, then the system must be simple and helpful to cater for the capabilities of this user population. It must also be efficient if people are to be able to achieve their task goal within the short time they are likely to have available.

In contrast the user of an air traffic control system is likely to face the problem of excess mental workload in controlling a region of airspace and so critical usability goals are likely to be: reduction in mental workload and avoidance of error.

Form 2.1 - General Usability Goals (Example)

2.1 General Usability Goals
System: Bank machine
User: General public
usability goal User requirement with respect to Goal Key Goals

Effectiveness
Quality or quantity of output/task completion.
It is important that the user be able to complete tasks accurately.

Efficiency
Time to perform task, time compared with an expert.
Users will expect to use the bank machine quickly and will become impatient if response times are slow.

Satisfaction
Perceived satisfaction or enjoyment in using the system.
The satisfaction from using the system will derive from completing a task successfully and quickly.  

Learnability
Ability to use the system help or manuals to perform the task.
Short instruction leaflets may be provided. However it is not expected that system will rely on on-line help.  

Intuitiveness
Ability to perform the tasks with limited introduction.
New users will be discouraged from using the system if it is not intuitive.

Helpfulness/supportiveness
Ability to overcome problems that arise.
The system should give some guidance if the users get stuck.  

Controllability
Perceived feeling of being in control/tracking performance etc.
Users should feel confident that they can operate the system and take suitable action if something unexpected happens.  

Avoiding excessive mental load
Perceived mental effort, or physical indicators.
The system should not require the user to remember a long PIN number.  

Avoiding excessive physical load
Heart rate, respiratory measurement.
People with motor impairment, and in wheelchairs should be able to operate the system comfortably.  

Safety
To be able to operate the system safely
The system must be sighted in a location in which users feel safe and should be well lit.

While all the above goals may have some relevance to a given system, it will be necessary to prioritise the goals, select those of most relevance and specify them more precisely as operational goals. The achievement of these goals is then a matter of subjective judgement by users or human factors experts.

Guidelines

There are many sets of guidelines that may be employed to assist in the design of a usable system. In Appendix 1, a series of general user interface guidelines are presented. Those involved in the development of the design concept and prototype should review them to make themselves aware, or to remind themselves of the main principles to bear in mind.

It is recommended to use a highlighter pen to highlight any phrases that are particularly relevant to the current application. It may also be helpful to produce a short checklist of items that should be remembered when developing the system design.

It is also necessary to review any internal design guides that need to be followed or de facto interface standards (e.g. Windows 95, Windows NT, OSF Motif). Later in section 3.10, a list of standards that the design should follow is also produced.


2.2 Identify design constraints
Back to Contents

NECTAR Home Page The NECTAR Information Update The NECTAR Repository The European Journal of Engineering for Information Society Applications The NECTAR Discussion Fora